The present disclosure relates generally to a method of testing computer programs and, in particular, to a method of testing computer programs that forces termination at specified points in the computer programs.
In computing systems, there are many system components and applications that create persistent objects (e.g., data sets, directories, files, file content, shared memory, semaphore sets, and message queues). Some persistent data objects only persist for the life of the initial program load (IPL), while others are hardened to a direct access storage device (DASD) and persistent across an IPL. Computer systems can become unusable for a variety of reasons including system errors, hardware problems and power outages. Computer applications, or programs, can be terminated unexpectedly due to programming error, terminating signals, operator cancel, etc. When a program that creates persistent data objects is interrupted due to any of the above computer system and/or computer application reasons, the persistent data objects left behind can be in an unpredictable state. When these applications are restarted after a system or application outage, they may fail to initialize properly due to the inconsistent state of the persistent data objects left behind after the last failure.
Some computer programs (also referred to herein as applications) provide a utility that will detect and delete all residual persistent data objects from a prior instance of the application. This always provides the computer program with a clean state to start from. This is generally acceptable when there is a single instance of the application, such that there is no consideration for other instances of the application running concurrently. Another approach to dealing with persistent objects is for the application to fail to restart after an abend, leaving it up to the user or system programmer to clean up any residual persistent data objects. This approach has drawbacks, because of the amount of knowledge required by the users of the program. In general, the more knowledge required by the user to clean up the residual objects, the less acceptable the product is to the user.
Another approach may be utilized by applications that have resources that persist for the life of the IPL. This approach requires the system to be re-IPLed (i.e., rebooted) in order to be able to start. For critical servers designed to operate continuously (i.e., 24/7), forcing a re-IPL is unacceptable and causes systems to miss their availability goals. A further approach is that some systems and applications are coded to cope with any residual data and to reuse the objects that are viable and delete those that are not. Depending on how many persistent data objects are involved and whether there can be multiple instances of the application trying to start at the same time, this logic to deal with an indeterminate state can be quite complex.
Computer programs that create and/or modify persistent objects should be tested to verify that the restart of the system or application functions as expected, regardless of where the previous instance of the application was interrupted. Often, the recovery flows are not fully tested and problems dealing with restart errors are frequently not detected for several years at which point it can be very difficult to debug and/or recreate the error. One approach to testing recovery of persistent objects is for programmers to modify the program to inject an error at a given point, recompile the program and execute the program to force the error. The programmer then removes the error injection code and recompiles again. This works for an initial test of the application, but the test is rarely repeated, even after significant programming changes are made to the module. It is also time consuming and error prone to constantly modify and recompile the program. In addition, programmers may utilize an interactive debugger to place breakpoints in a program to force a stopping point in the program. This can be very time consuming and is rarely repeated after the initial unit testing is completed.
An automated and easily repeatable method for testing computer programs that create persistent data objects would facilitate the testing of applications and would lead to higher quality application programs.